Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Look for Multiple Bugs

Sometimes more than one bug contributes to a single incorrect behavior. You may find a bug and think it is the sole cause of the problem. Before you declare the problem solved, look for other bugs that may have contributed to the incorrect behavior.

Also look for other bugs that may have been hidden by the bug you found. The bug you found may have prevented another bug from becoming obvious. Look for it now, before you declare the code fixed.

Even completely correct bug fixes may create new bugs. If a routine has contained a bug for a long time, other routines may have been written that depend on its buggy behavior. When you finally repair the bug, those other routines may fail. Look for this sort of bug now. If you find the bug now, you will know exactly why the other routine failed. If you experience a problem later, you may have no idea why the code no longer works.

Do Not Experiment

Do not experiment with the code. Do not try making a change to see what happens. This is one of the worst ways to debug. It is much better to examine the routine as a whole and figure out what it is supposed to do. Then you can analyze what it actually does and find the problem.

Many programmers begin debugging by stepping through a routine in the debugger. As soon as they see the code start to diverge from what they expect, they stop, change the code, and then run the program again. Without a complete understanding of the routine, the change is as likely to break the routine as to fix it.

Know what you are doing before you make changes. Do not guess.

Test Fixes

Changes to existing code produce more bugs per line of code than originally writing the code does. There are several reasons for this. When you write a routine originally, you must understand the whole routine. When you debug, you may be lazy and try to fix the code without fully understanding it all.

Code changed during debugging also tends to involve the most complicated statements. Simple assignment statements and variable declarations occasionally contain bugs, but complicated If Then statements and While loops are far more likely to be wrong. Because the statements most likely to contain errors are complex, you are more likely to make a mistake while changing them.

Since the odds of making a mistake are greater when you fix bugs, you must thoroughly test your changes. Test the code even if you are absolutely positive the change cannot have caused any other problems. The most obviously correct code often hides the bugs that are hardest to find.

Simplify

As is mentioned in the previous section, code changed during debugging tends to involve the most complicated statements. When you debug a very complex statement, simplify it. That will help you make the change correctly and will make debugging easier in the future if you do make a mistake.

For example, the following If statement is complicated and confusing. It is supposed to determine whether a game program should display intermediate moves while the computer is calculating a move. Unfortunately, it contains a bug that makes it call DisplayMove only when the Winner object does not have the value Nothing. That only happens when the game is over and the computer cannot be moving. Therefore, the program never displays intermediate moves.

‘ If we are showing intermediate moves, and the computer
‘ is moving, and the game is in progress, show the move.
If chkShowMoves.Value = vbChecked And _    
    PlayerMoving Is PlayerComputer And _    
    Not (Winner Is Nothing) Then _
        DisplayMove

The following version fixes the bug and makes the If statement easier to understand. If there is a problem with this statement in the future, it will be easier to understand and fix.

Dim show_moves As Boolean
Dim computer_moving As Boolean
Dim game_continuing As Boolean

    ‘ If we are showing intermediate moves, and the computer    
    ‘ is moving, and the game is in progress, show the move.    
    show_moves = (chkShowMoves.Value = vbChecked)    
    computer_moving = (PlayerMoving Is PlayerComputer)    
    game_continuing = (Winner Is Nothing)    
    

    If show_moves And _        
        computer_moving And _        
        game_continuing _
    Then DisplayMove

While you should simplify statements that contain bugs, resist the urge to modify code that works. When you fix a bug, you need to thoroughly test the code to see if the change works and to catch any new bugs you may have created or uncovered. Simplifying the code while you fix a bug will not add much time to the task because you need to test the code anyway.

On the other hand, if you make changes to working code, you should spend extra time testing the changes or you run the risk of introducing new bugs in code that worked before. Save time and effort by leaving the working code alone. If it isn’t broken, don’t fix it, or it soon will be.

Examine Decisions Closely

When you review a routine that contains a bug, pay special attention to the places where the code makes decisions. If the program makes a decision, it can make the wrong decision.

If, Select, For, and While statements contain program logic that may contain bugs. Simple calculations and variable declarations are less likely to contain errors. Concentrate on the more complex decision statements.

Look for Bugs Where There Are Bugs

Intuition may lead you believe that a routine that contained many bugs in the past would contain few bugs now. After all, if a lot of bugs have been fixed, there cannot be many left.

Actually, the opposite is true. Code that contained many bugs in the past will probably contain more bugs in the future. This is due partly to the fact that repairing a bug is likely to introduce a new bug. It also reflects the fact that a buggy routine is probably not well designed. It may not perform a well-defined, tightly focused task. It may be fragmented with related code scattered throughout. It may be too complex to fit into one routine or it may simply have misleading comments. For whatever reason, programmers have had trouble understanding and fixing this routine in the past and they probably will in the future.

Look for bugs where there have been bugs in the past. Keep track of which routines are buggy so it is easy to tell which ones are causing problems. If you insert comments into the code as you fix the bugs, you can use them to determine which routines have held bugs in the past.

At some point, when a routine has wasted enough of your time, you should consider throwing it away and completely rewriting it. If you invest the time to properly design, implement, and test the routine, it may never give you trouble again.

Self-Test

This Self-Test section contains a debugging problem. The Bad16 program, shown in Figure 16.1, draws a histogram on a shaded background. The program works, but it takes roughly three seconds for the form to load on a 133-megahertz Pentium. This should take less than half a second.